Subject: Proteon's use of multicast

From: [email-masked] (Michael Redden)
Date: Wed, 13 Sep 1995 20:27:59 -0400 (EDT)

This is an introduction to Proteon's use of multicast for peer discovery.  I
hope that this introduction will generate ideas and discussions for using
multicast to address some of the scalability problems.  Additional details
about the implementation are available should the RIG decide to implement all
or part of this protocol.

Mike Redden
[email-masked]
 
When first designing our DLSw implementation at Proteon, we realized that there
would be a large administrative burden when configuring DLSw for a traditional
hierarchical one-to-many network.  The problem is that there must be some way 
of defining the DLSw partners to establish TCP connections with.  If each DLSw
partner that a DLSw router wishes to connect to must be defined individually
by IP address, it becomes way too much work for the user.  In addition, each 
time a new remote DLSw partner is added to the network, the configuration of 
the DLSw partners it wishes to connect to must be changed.

One solution to this problem is to accept TCP connections from any partner.  
By choosing this solution, the IP address of the partner to connect to only 
has to be configured in one of the two partner routers.  This helps a lot for
the one-to-many case, but doesn't do much to reduce the configuration that
must be done in the meshed network case that is typical of NetBIOS networks.

The final solution that we came up with is what we call DLSw multicast groups.
Each DLSw partner can be configured to be a member of one or more groups.  By
using multicast OSPF routing of UDP datagrams to other members of the same
group, the DLSw partners in the group can locate and establish TCP connections
with each other.  

Multicast groups is an enhancement to DLSw.  If a DLSw partner does not support
multicast groups, the TCP connection to the partner may be configured by 
specifying the IP address of the partner.  Thus compatibility with other
implementations not supporting multicast groups is maintained.

A DLSw partner may be a member of up to 64 different groups.
Within each group there are three roles, client, server and peer.  Clients
in a group only establish TCP connections with servers in the same group.
Peers only establish connections with other peers in the same group.  So for
the one-to-many configuration, the hub site partner could be configured to be 
a server in a group, and all the remote partners could be configured to be the
clients within the same group.  For a mesh network where every partner must 
establish a TCP connection to every other partner, each DLSw partner could be
configured as a peer within a specific multicast group.  Each peer would
locate and establish a TCP connection with every other peer in the group.

Multicast OSPF routing is used for sending messages between partners in the 
same group, so that they may locate each other and establish a TCP connection.
Different multicast addresses are used for each group and role within a group.
For each group and role, the DLSw code registers with the multicast OSPF code
the fact that it wishes to receive data received with a destination address 
equal to the multicast address that is used for that group and role.  

The algorithm for allocating multicast addresses to the groups and roles is 
as follows.  All multicast addresses start with a base multicast address 
of 225.0.1.0.  For a client in a group, the group number is simply added to
the address.  For example, a client in group one would register the address
225.0.1.1 with the multicast code so that it will receive multicast messages
destined for this address.  For a server or peer in a group, the group number 
plus 64 is added to the base address.  For example, a server in group one
would register an address of 225.0.1.65.

A specific UDP port is used for all DLSw group messages, and the DLSw code
must register with the UDP code the fact that it wishes to receive the UDP 
messages sent to that UDP port.  The UDP port number used for DLSw multicast
group data is 0x8010.

When a DLSw partner is first started, it registers with the multicast OSPF
code all the multicast addresses for all the groups and roles configured.  It
also registers with UDP so that it may receive any UDP datagrams received for
the DLSw group UDP port.  It then makes up a list of multicast addresses that
it should send what we call group packets to.  The messages sent by DLSw
partners via multicast when searching for partners are group packets.

The group packet contains, among other things, the IP address of the sending 
partner, the role of the sending partner, and the group number.  When a group
packet is received and the TCP connection to the sending DLSw partner has not
yet been established,  the TCP connection is opened, and a group packet is sent
as a response to let the sender know that it should also open the TCP 
connection.

The group packets are sent via multicast at periodic intervals.  Upon 
initialization, six sets of group packets are sent at fifteen second 
intervals to every multicast address used for the groups and roles that the
DLSw partner is a member of.  After the first set of six have been sent, 
the interval between the transmission of the group packets is increased to 
a user configurable interval.  The default value for this interval is 900 
seconds.

I would like to propose some changes to our use of multicast groups to adapt
it for use in solving the scalability problem.  Firstly, the concept 
of separate distinct multicast groups and roles should be maintained.
This provides a nice partitioning of the DLSw partners when a mesh of TCP
connections is not necessary between all of the partners.

The multicast groups implemented at Proteon is only used as a discovery
mechanism to find other partners to establish TCP connections with.  I would
propose that instead of simply locating the potential DLSw partners, the 
multicast mechanism be used for the "broadcast" of the CUR-ex and the 
NetBIOS-NQ-ex before the TCP connections are established.  The TCP connection
is only established on demand after the receipt of the equivalent of ICR-ex or
NetBIOS-NR-ex via the multicast mechanism.  This would reduce the broadcast 
overhead and establish TCP connections only when necessary.  Some type of
retry mechanism must be implemented because of the unreliable nature of the 
multicast UDP datagrams as we discussed at the RIG meeting.

I am also proposing that additional multicast addresses can be used to imply 
support of SAPs, so that the explorer traffic would be sent only to DLSw 
partners that support traffic for the specified source SAP.  There would be
a separate multicast address for each combination of group, role and supported
SAP configured.  This provides a function equivalent to the filtering that the 
supported SAP list in the CAPEX messages allows.